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1.0 Introduction 

1.1 Purpose and Objectives of Document 

The Space Telecommunications Radio System (STRS) Architecture Requirements Document 
provides the basis for the development of an open architecture for NASA Software Defined Radios 
(SDRs) for space use. The STRS project is currently under the direction of the Space Communication and 
Navigation (SCaN) Program. The STRS program encompasses many aspects related to the use of SDRs 
for NASA including: 

1. Development of the STRS standard for SDRs 

2. Inclusion of non-NASA entities for standards development and implementation, including other 
Government agencies, international and domestic industry, SDR forums and organizations, and 
academia 

3. Development of design tools and validation test beds for standard-compliant SDRs 

4. Development of standard-compliant hardware and software library components from which a 
variety of SDR types may be tailored for specific missions 

5. Development of a Business Case Analysis for both SDRs in general and SDR standardization, 
including case studies of past NASA programs 

6. Development of an SDR acquisition model tailored to the specific needs of SDR design, 
development, test and evaluation programs 

7. Performance of an SDR application study using the NASA Space Exploration Mission Model for 
recommending SDR designs for specific missions and mission types 

8. Development of Design Reference Implementation Specifications for reference in creating 
specific SDR designs 

9. Compilation of an SDR technologies database identifying imminent and long term technologies 
needed to realize near-term and future SDR designs 

10. Compilation of an industry and Government organizations SDR designs database identifying 
specific SDR design implementations currently available, in- work, and planned 

11. Evaluation of the DoD Joint Tactical Radio System Program for cooperative efforts 

The requirements stated within this document only address item #1 : Development of the STRS 
standard for SDRs. 

1.2 Scope of Document 

This document describes the requirements of the Space Telecommunication Radio System 
Architecture. These requirements were developed as follows: The Top-Level Customer Guidelines are 
provided by NASA Headquarters. They provide requirements intended to guide the broader and longer- 
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term aspects of the SDR Architecture. The goals and objectives are derived from the Top-Level Customer 
Guidelines. They provide broad, fundamental direction and purpose. They are not meant to be verifiable. 
Level 1 requirements are derived from the goals and objectives and are verifiable but are not intended to 
be verified directly. They will be decomposed into further requirements (Level 2 requirements) which 
will be verified. The Level 1 requirements are considered verified after all of the decomposed (Level 2) 
requirements are verified. 

1.3 Document Overview 

The document is divided into sections. Section 1 introduces the reader to the document. Section 2 
provides the list related documentation. Section 3 describes the Top-Level Customer guidelines. Section 4 
describes the STRS goals and objectives. Section 5 describes the derived system requirements that 
identify the architecture consideration for this study. Section 6 provides the list abbreviations and 
acronyms related to the document. 

2.0 Related Documentation 

Document Number Document Title 

STRS-DA-00001 Space Telecommunications Radio System STRS Definitions and Acronyms 

3.0 Top Level Customer Guidelines 

Guidelines were provided by NASA Headquarters and are stated below without modification. They 
have been designated the “Customer Guidelines”. 

Compared to traditional NASA-developed communications assets, the standard SDR architecture 
should provide for: 

1. Flexibility with broad application through adaptability and evolution to many NASA mission 
types from 2015 to 2030 (flight years) 

2. Lower agency-level cost and risk across all missions 

3. Faster development from mission requirements determination through flight hardware delivery 

4. Use of a high degree of non-proprietary design, development and operation 

5. Multi-Center participation in architecture development 

6. Be adaptable to evolving requirements through 2030 

7. Accommodate technology advances through 2030 


4.0 STRS Goals and Objectives 

The goals and objectives clarify and expand on the Top-Level Customer Guidelines. They provide 
broad, fundamental direction and purpose. They are not meant to be verifiable. 

4.1 Usable Across Most NASA Mission Types (Scalability and Flexibility) 

Rationale : The architecture approach allows the adoption of different implementations for most 
mission classes. The architecture will not be usable if excessive burden (such as Size, Weight, and Power 
(SWaP) and complexity) is needed for a single mission to realize the multi-mission benefits. It also 
should be usable with the computing elements capable of operating in the space environment. This 
includes the capability to eliminate or mitigate long and short term radiation effects, perform in a vacuum, 
and operate in extreme temperatures. The radio should also survive the effects of launch including Near 
Strike Lightning (NSL) to the extent that full performance can be restored. The capabilities of elements 
that can operate in this environment lag behind the capabilities of ground environment elements. The 
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impact to the STRS architecture will be the performance and capacity of the components that are rated for 
space environment. The architecture is expected to apply to the majority of missions with the realization 
that a few missions should be allowed waivers to develop a non-fully STRS conformant radio. 

4.2 Decrease Development Time and Cost 

Rationale : NASA HQ has given us the challenge to lower cost and risk and decrease the development 
time of software defined radios. Complex reliable software can become very costly in terms of dollars and 
development time. With standard functions and interfaces defined by the architecture, code is more easily 
reused. 

4.3 Increase Reliability of Software Defined Radios 

Rationale : Managing the complexity of the design through a common architecture and reducing the 
amount of interdependence on other systems will enhance reliability. Common qualification processes 
and procedures will allow for improved testing methods as flaws in previous procedures are discovered 
and new methods are developed. 

4.4 Accommodate Advances in Technology With Minimal Rework (Extensibility) 

Rationale: Technology advances will continue to provide greater processing power and memory and 
require less size, weight, and power. The architecture should also be able to accommodate the current and 
future evolution to advanced SDR concepts such as Ideal Software Radios (direct digital sampling at the 
antenna port) and Cognitive Radios, and should be extendable to interface with optical communication 
systems. 

4.5 Adaptable to Evolving Requirements (Adaptability) 

Rationale: Future missions may have requirements for operations or capabilities that have not 
currently been considered. For example, a higher level of security support may be required and the 
architecture should adapt to accommodate this new need. 

4.6 Enable Over the Air Interoperability With Existing Assets (Interoperability) 

Rationale : The existing communication infrastructure typically needs to be operational for many 
years. As radio technology evolves, it is usually not feasible to upgrade all existing assets in order to 
operate over the air with new systems. 

4.7 Leverage Existing or Developing Standards, Resources, and Experience (State-of-the-Art and 
State-of-Practices) 

Rationale : Space radio vendors are building and deploying software defined radios. Given the limited 
number of radios that will be procured by NASA, aligning with current approaches to the extent possible 
is necessary. Leveraging their software and hardware development and products to the extent reasonable 
may reduce NASA’s costs and risks. Deviating from current practices would increase design cost and 
schedule and decrease reliability. 

4.8 Maintain Vendor Independence 

Rationale : Not relying on a single vendor will reduce operation and maintenance costs and reduce the 
risk that the vendor will not support future modifications which will be inherent to SDR operations. 
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4.9 Enable Waveform Application Portability 

Rationale : The number of waveforms being used by NASA is limited and unlikely to increase or 
dramatically change. Reusing all or part of the code for this limited number of waveforms will decrease 
development time and cost and increase reliability. 

5.0 STRS Level 1 Requirements 

STRS Architecture Requirements support a NASA perspective that often spans multiple missions. 
These requirements address how the various mission classes are expected to use the architecture. The 
following sections list the Level 1 requirements, which were derived from the Goals/Objectives. 

These requirements are intended to address the STRS Architecture, not a specific implementation. An 
implementation may not require all aspects of the architecture; therefore, all requirements may not apply 
to each STRS-compliant software defined radio. The architecture specification will evolve depending on 
available technology and capabilities. Some requirements may not apply to near term applications. 

5.1 Layered Architecture 

The STRS Architecture shall be layered to isolate waveform applications from hardware specific 
implementations. 

Rationale : Layering provides a means of maximizing hardware abstraction, portability, and 
technology insertion. Layering promotes waveform application portability to alternate platforms that 
conform to the architecture. 

5.2 Open Architecture 

The STRS Architecture shall utilize an Open System Architecture approach. 

Rationale : A System Architecture approach is comprehensive set of functions, components, and 
design rules according to which radio communication systems can be organized, designed, constructed, 
deployed, operated, and evolved over time. A useful architecture partitions functions and components 
such that a) functions are assigned to components clearly and b) physical interfaces among components 
correspond to logical interfaces among functions. When functions, interfaces, components, and/or design 
rules are defined and published, the architecture is open. Open architectures facilitates interoperability 
among commercial and Government developers and minimizes the operational impact of upgrading 
hardware and software components. 

5.3 Flexibility in Form Factor 

The STRS Architecture shall allow the radio to be flexible in physical form factor. 

Rationale: The radio will need to be configured into different physical form factors to meet mission 
size, weight, and power requirements. These form factors will require the ability to be sized based on the 
hardware required to implement the waveform functions. The architecture is specified as platform 
independent and scalable to address mission requirements. 

5.4 Remote Reconfiguration 

The STRS Architecture shall allow the radio to maintain reliable operation during remote partial and 
full reconfiguration of firmware and software. 

Rationale: Firmware and software reconfiguration in the operational environment enables 
modification of radio units post-launch to meet varying mission needs without loading new firmware or 
software. 
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5.5 Remote Reprogrammability 

The STRS Architecture shall allow the radio to maintain reliable operation during remote partial and 
full software and firmware uploads. 

Rationale: This capability will allow the radio units to maintain communication and operational 
status during the reload process. The upgrade can then be implemented upon the next boot or startup. 
Reprogrammability provides the ability to correct latent software defects or implement new capabilities. 

5.6 External Hardware Control 

The STRS Architecture shall allow the radio to control external hardware in real-time. 

Rationale: This capability will allow the radio to set and modify parameters to external hardware. For 
instance, tuning external RF hardware within specified frequency bands to avoid external interference 
sources and changing the output level of the power amplifier. This potentially eliminates additional front- 
end hardware sets. 

5.7 Standard Spacecraft Interfaces 

The STRS Architecture shall allow the radio to use standard spacecraft interfaces. 

Rationale : The radio will be employed on platforms using standard spacecraft interfaces for power. 
The radio will need to exchange voice, video, and data with spacecraft systems using the common 
spacecraft software and hardware interfaces. Utilization of common spacecraft busses also enables the 
radio and other devices on the spacecraft bus to share excess resources such as processing power. 

5.8 Existing Waveform Support 

The STRS Architecture shall allow the radio to operate legacy, current standard, and defined 
waveforms. 

Rationale: The radio must be capable of interoperability with current and legacy waveforms to 
support existing networks while providing a transition path to future systems. 

5.9 Multiple Waveform Support 

The STRS Architecture shall allow the radio to operate more than one waveform. 

Rationale: Missions typically require communications using more than one waveform, such as a 
mission that requires different waveforms during different phases or a mission that must use both GPS 
and TDRS. By having a single radio be capable of running more than one waveform, this can reduce the 
number of radios for a mission. 

5.10 Simultaneous Operation of Multiple Waveforms 

The STRS Architecture shall allow the radio to operate multiple waveforms simultaneously. 
Rationale: Missions typically require Telemetry, Tracking and Control (TT&C) as well as mission 
data transmission capability simultaneously. The radio could also be used for simultaneous GPS 
reception, thus eliminating the need for a separate receiver. 

5.11 Multi-Service Support 

The STRS Architecture shall allow the radio to use both narrowband and wideband waveforms for 
voice, video, and data space communications. 

Rationale: The NASA users operating across the operational continuum must communicate with 
users that employ radio systems with a wide variety of waveforms and technological maturity. 
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5.12 Suitable for Any Radio Frequency Bands 

The STRS Architecture shall allow the radio to operate with any frequency band within VHF to high 
frequency optical. 

Rationale : The architecture should not limit the range of frequencies that radio implementations can 
operate with. NASA missions typically need to use low frequency bands for telemetry, and high 
frequency bands for science data. Future NASA missions will probably need significantly larger science 
data transfers from space, requiring even higher frequency bands to be implemented. It is envisioned that 
future NASA missions will utilize optical communications, for direct to Earth and for inter-satellite links. 
As a result, the STRS baseband unit should be capable of interfacing to optical communications 
hardware. 

5.13 Multiple Frequency Bands 

The STRS Architecture shall allow the radio to operate in several communication bands 
simultaneously. 

Rationale: Different missions may require communication via different relay satellites or ground 
stations. Longer duration missions especially may need to adapt to using different frequency bands. For 
the foreseeable future, the frequency band will probably be determined by the pre-launch installed RF 
components in order to reduce weight, power, and complexity. 

5.14 Multi-Channel Capability 

The STRS Architecture shall allow the radio to operate multiple simultaneous channels in a single 
communication band. 

Rationale: For example, this allows for the case where a mission requires that high criticality data be 
sent using a different channel than lower criticality data. Multiple simultaneous channels can also allow 
for increased throughput or redundancy. 

5.15 Commanded Built-In-Test and Status Reporting 

The STRS Architecture shall allow the radio to provide a Built-In-Test (BIT) and status of the radio 
functionality, and last known configuration when interrogated remotely. 

Rationale: This capability provides a means of accessing data that can be used to identify faults, as 
well as providing valuable configuration information. This will increase reliability and availability by 
increasing understanding of the nature of a problem leading to a faster recovery, as well as supplying 
additional information to assist in improving future designs and procedures. 

5.16 Operational Diagnostics 

The STRS Architecture shall allow the radio to detect extended loss of operation either due to signal 
degradation or due to internal malfunction. 

Rationale: This capability will increase reliability and availability by allowing faster detection of a 
problem leading to a quicker recovery. This is not a BIT but a behavior based on operational activity. The 
radio detects a problem and then may issue BITs to attempt to determine if the signal loss is due to 
hardware or external factors. 

5.17 Automated System Recovery/Initialization 

The STRS Architecture shall allow the radio to autonomously recover from fault conditions after 
reboot or power cycle. 
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Rationale: Recovery of the radio to an operational state after a fault condition (e.g., power loss, failed 
uploads, software errors, Single Event Upsets) will support critical continuity of operations. The radio 
must be able to return to full operation (restores back to last radio configuration/parameters/operational 
settings prior to fault condition) without need for external equipment or procedures. A radio may recover 
from an internal error without the need to reboot or power cycle, however that is not a requirement of the 
architecture. 

5.18 Navigation Support 

The STRS Architecture shall allow the radio to use current, and be adaptable to new, radiometric 
tracking and navigation waveforms and services. 

Rationale : Radiometric data is collected to provide measurements used to produce estimates of the 
user’s trajectory, including position, velocity, and time. Integrating the communication and tracking 
system into a single radio reduces the overall required RF spectrum, mass, power, and volume allocations. 
Special considerations will be required in the design and implementation of the radio to implement the 
integrated system. 

5.19 Network Support 

The STRS Architecture shall allow the radio to use current, and be adaptable to new, networking 
protocols. 

Rationale: This includes Consultative Committee for Space Data Systems (CCSDS) and Internet 
Protocol (IP) including a network infrastructure comprised of dispersed network elements using various 
communications transport capabilities. CCSDS and IP are in common use in many existing systems and 
have been used in several NASA missions. New delay tolerant protocols are being considered and the 
architecture must adapt to support these and other future protocols. 

5.20 Security Compatibility 

The STRS Architecture shall allow the radio to be compatible with current, and be adaptable to new, 
security measures. 

Rationale: The radio will require the functionality of certain legacy equipment for backwards 
compatibility as well as current security measures required to protect capability and waveform s . 

5.21 Secure Transmission 

The STRS Architecture shall allow the radio to use secure transmission. 

Rationale: Transmission security shall deny unauthorized access to information while being 
transported over the radio to protect capabilities and waveforms. 

5.22 Processor Sharing 

The STRS Architecture shall allow the radio to be reconfigurable to provide additional computing 
resources at times when communications are low or zero. 

Rationale: The radio may not need to perform its communications functions at all times. Agency cost 
and risk can be reduced by sharing these unused computing resources with other devices (e.g., science 
experiment computer) using standard spacecraft interfaces. 

5.23 Autonomous Link Optimization 

The STRS Architecture shall allow the radio to autonomously monitor the communications 
environment and self-adapt to optimize the communications li nk . 
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Rationale'. Optimization can increase availability of the link, allowing the radio to be used in 
missions where link conditions could vary. This optimization can include changes to the modulation and 
coding schemes (e.g., use a lower coding rate in favorable link conditions). This capability makes it 
possible to “fine-tune” the communication link much more accurately than an operator could perform a 
similar function. 
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This traceability matrix was generated to understand how the STRS Goals and Objectives traced and mapped to the STRS Level 1 
Requirements. The purpose of this matrix is to assure that all Requirements support at least one Goal/Objective, and that all Goals/Objectives are 
captured in Requirements. The lack of an “X” does not necessarily mean that a mapping does not exist between the requirement and the 
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API 

BIT 

CCSDS 

DoD 

IP 

NSL 

RF 

SCaN 

SDR 

STRS 

SWaP 

TT&C 

VHF 


Appendix A — Abbreviations and Acronyms 

Application Programmer Interface 
Built-In-Test 

Consultative Committee for Space Data Systems 

Department of Defense 

Internet Protocol 

Near Strike Lightning 

Radio Frequency 

Space Communication and Navigation 
Software Defined Radio 
Space Telecommunications Radio System 
Size, Weight, and Power 
Telemetry, Tracking And Control 
Very High Frequency 
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